SDD 2023 started out with a fullday workshop and I choose to attend Alan Holubs workshop on microservices. I have attended talks with Alan Holub before, and he is truly a great speaker. He is very good at getting the audience involved and he does have some opinions that can be a bit provocative. But I actually like the provocative opinions, because it really makes you take a step back and see the way we do things from another perspective and that is something that can be really rewarding in the long run.

So what is a microservice? 

1. An application single, small and clear responsibility
   1.  A biproduct is that the code base is very small 
2. Independently deployable
   
   1. Can be deployed without other applications needing to know and without other applications needing to be deployed simultaniously
3. Decentralized
   
   1. Can be deployed anywhere and do not rely on other services or applications being deployed in the same datacenter or environment
   2. Cannot share a database with other applications or services
   3. Should enforce authentication and authorization
4. Fully autonomous
   
   1. Can handle faults and spike loads. Will not let faults ripple to other services
5. Highly observable
   
   1. There is a need for good logging and monitoring of a microservice in order for the team to react, analyze and solve problems very fast

One of the main differences from the monolithic architecture, is that microservices are completely independent. That means that they do not share a database with other microservices. They might have a database of their own, to support the work that they are doing, but they will never have access to a database that is shared between other microservices. This is a quite a big change, when you compare to the way a monolithic application works, where each service in the monolith have access to the same database.  

"You want to avoid a situation where one change results in deployment of multiple services" - Allan Holub

Notify the tiny titans

All data that the microservice need must be served when the microservice is invoked. This typically happens in one of two ways. Either the microservice has a subscriber that subscribes to messages on an event bus (ie. RabbitMQ, Azure Service Bus, ZeroMQ) - this is the most normal and effective approach. Some microservices have a requirement to be able to receive requests from "the outside world" and have a REST interface. This approach should be held to a minimum due to the performance hit of HTTP requests.

Microservices are hard

Microservices is not a silver bullet though. The architecture has to be well planned and implemented with good attention to detail - if it's not, it can be even more complex than the good old monolith architecture that we all (most of us anyway) are trying to get away from. But if you implement it with a solid plan and attention to detail, microservices can be a very liberating architecture to work with. But it is very important to understand that creating a microservice architecture will introduce complexity and will require you to handle problems that is not prevalent in a classic monolithic architecture.

Tiny footprints for tiny titans

In order to mitigate the complexity that is introduced to the overall architecture, when you start to implement microservices, it is recommended to keep the implementation of the individual microservice as simple as possible. For instance if you need to temporarily store some data, then save it in a file using JSON. File read and writes are plenty fast and as long as it is not holding thounds of rows of data, a file can fulfill the need. Do not be tempted to add a database unless you absolutely need it. It will only add to the complexity of the overall solution, because you need to set up the pipeline to maintain the databaes (and you have to pay for it as well!).

Conclusion

In the vast software kingdom, microservices have emerged as the rulers, dethroning the monolithic giants of the past. Their agility, decentralization, and scalability have paved the way for a new era in software development. As we conclude this exploration, it's clear that the tiny titans of microservices will continue to shape the software landscape, offering new possibilities and unleashing the potential for innovation. Long live the reign of microservices in the software kingdom!